Current chipsets, such as those used to implement core cellular and other communication standards, are delivered to customers with built-in support for authentication at boot. This means that, upon booting a given chipset, the chipset's firmware checks the authenticity of the initial software (called SW Boot) with respect to, e.g., a cryptographic key, and executes said software only if the check is successful.
However, in a final customer product, the cryptographic key (public key) used during this verification is customer-dependent and usually generated by the customer. In order to avoid production issues (different provisioning between customers and even between chipsets dedicated to different products of the same customer), the public key used by the chipset firmware to check the SW Boot is thus provisioned by the customer—which may be regarded as a “final” customer public key. Usually, the location for provisioning this key is a one-time-programmable (OTP) memory embedded in the chipset.
However, when the final customer public key is not yet provisioned, it is dangerous to allow the execution of a SW Boot that has not been checked in any way. Indeed, allowing execution of an unverified SW Boot opens the door to counterfeiting in cases where empty chipsets are stolen. That is, a counterfeiter could provision empty chipsets with the same data as a legitimate customer, and then run that customer's software. Therefore, there are known integrity checks that are performed for chipsets when the final customer public key is not provisioned yet.
In one example flow, the chipset firmware checks the SW Boot integrity as follows: (1) a customer public key is retrieved from the SW Boot, together with a customer public key certificate; (2) the customer public key certificate is verified with respect to a root key embedded in the firmware, meaning that the customer public key has been validated by the owner of the firmware root key (usually the chipset manufacturer); and (3) if the validation is successful, the customer public key is used to verify the SW Boot. This method allows for controlling the chipsets until they are provisioned with a final customer public key in OTP.
If the customer public key is provisioned in OTP then steps (1) and (2) are omitted and the customer public key used in the verification of the SW Boot in step (3) is obtained from OTP. To save OTP memory, it is possible to store the customer public key as part of the SW Boot and only store the cryptographic hash of the public key in OTP. In this case, an extra step is introduced before step (3) in which the hash of the customer public key obtained from the SW Boot is computed and checked against the stored hash of the customer public key in OTP.
The provisioning of the customer public key (or customer public key hash) can be done only after executing a SW Boot signed by a customer public key, which has been certified by the firmware root key. The SW Boot may then write into the OTP of the chipset the final customer public key (or customer public key hash), which may differ from the one certified by the firmware root key. Therefore, the private part of a customer key (customer private key used to sign the SW Boot, corresponding to the customer public key used to verify it) is especially sensitive. That is, a customer private key can be used to take control of empty chipsets and, therefore, the loss or compromise of such data is a significant security risk.
Indeed, in cases where a customer private key is lost or compromised, it is necessary to protect against unauthorized use of chipsets that are not yet shipped to the compromised customer (or others). A revocation process is used, wherein a verification number is stored by the chipset manufacturer into the chipset OTPs before delivery to any customer. In turn, the verification number is also included in the customer public key certificates of all authorized customers of the chipsets. Such a listing is part of the data items certified by the chipset firmware root key.
More particularly, when checking a customer public key certificate, the chipset firmware also verifies that the number that it reads from its OTP matches one of the numbers present in the customer public key certificate. Unless a match is found, the chipset firmware will not execute the SW Boot. Revocation in this manner works as follows: if a customer private key is lost, then newly produced chipsets are provisioned with a new verification number in OTP that does not match any of the verification numbers contained in the customer public key certificates that are in the possession of the authorized customers of the chipset.
One issue with the above approach is that, if a customer public key is revoked, then a new, not used yet verification number must be provisioned in the chipsets. Adding this new verification number will, as desired, disallow verification with the compromised customer certificate. However, the change also invalidates the other customer certificates, as they will not include the new verification number. Hence, with the loss or compromise of one customer's private key data, it is necessary to re-certify all other customers.
An alternative would be to manage verification numbers or other data for each customer separately. However, doing so requires that chipsets targeted for one customer be loaded with different verification data than those targeted for another customer. These different verification data provisions make the manufacturing and inventory control of chipsets more difficult, particularly when a plurality of customers uses the same type of chipset.